1. Field of Invention
The present invention relates generally to the field of database caching. More specifically, the present invention is related to local cache consistency maintenance with respect to one or more backend databases.
2. Discussion of Prior Art
Transactional Web Applications (TWAs) have recently reached widespread use in modern enterprise application infrastructures. Such applications are typically implemented within a broad range of technologies including network load balancers, HTTP servers, application servers, transaction-processing monitors, and databases. In its simplest form, a TWA is associated with an HTTP server hosting presentation logic, and with an application server hosting business logic (e.g., Java servlets or EJBs). A TWA is provided with data obtained from queries, issued by an application server, to a relational database. FIG. 1 depicts a prior art example of an enterprise application configuration.
Typical TWA operations include browsing a product catalog, populating a shopping cart or a wish list, placing the order, and checking order status. Requests from TWAs go through several layers of computer systems as shown in FIG. 1. Caching can occur at different granularity at each layer. For example, HTML pages can be cached at proxy servers inside the Internet, or at reverse proxy servers within the enterprise infrastructure. Web servers can cache fragments of HTML pages, and application servers can cache business objects, all of which lead to an increase in the performance of TWAs at different levels.
Caching static HTML pages and data as a technique to achieve better scalability and faster response time of interactive TWAs has long since been popular. Caching takes place in various forms: a cache for a client browser, forward and reverse proxy caches, nodes of content-delivery overlay networks, and in specialized object caches associated with application business logic. Combining caching technologies at various levels in an application infrastructure stack often adversely affects response time and scalability. However, as web pages become more dynamic and equipped with increased personalization capabilities, such static HTML caching techniques become less useful in supporting the delivery of high volumes of frequently updated information. High-volume web sites often serve highly personalized content to their users.
As a consequence, reusability of generated web pages is low, and data needed to build a web page often cannot be profitably cached far away from those enterprise application servers housing business logic that manipulates such data. For this reason, some enterprise applications run their business logic on application server nodes deployed in remote data centers that are proximate to users (e.g., web-hosting services). Partnerships between content-delivery network service providers (e.g., Akamai Technologies Incorporated) and application server vendors (e.g., IBM Corporation and BEA Systems Incorporated) facilitate the transfer of content and applications from origin enterprise servers, thereby improving response times and reducing the load on local, in-house systems. These approaches, however, are limited in their provision of access from remote application servers to central backend databases on origin enterprise servers.
Addressing this limitation is a promising technique capable of handling the dynamic nature of TWAs: database caching. Data stored in a database cache is obtained by a remote application server via database queries in the same manner as would be obtained by direct, backend database access.
There are a number of different options addressing a database cache entity implementation; semantic caching as disclosed by Dar et al. in the non-patent literature entitled “Semantic Data Caching and Replacement” and DBProxy as disclosed by Amiri et al. in the non-patent literature entitled “DBProxy: A Dynamic Data Cache for Web Applications” are two of such implementations. In these implementations, query results are locally stored in a cache; this cache is consulted for each new query to determine whether a result can be produced solely from local data. By contrast, other caching approaches describe systems in which a full-fledged database server is collocated with an application server.
One advantage of the latter approach is that a significant portion of query parsing and analysis logic that already exists in a full-fledged database system can be exploited to manage a cache. Such an approach also enables caching of other associated database objects, such as triggers, constraints, indices, and stored procedures. In this manner, application performance and semantics are provided along with uninterrupted service when backend databases are unavailable.
A simple approach to implementing a database cache would be to replicate full content of selected tables from a backend database. In this case, each cache table referred to in a query can be used as long as stale data is acceptable. However, front-end systems are much less powerful than backend systems thus making full-table caching more difficult. Even for a powerful front-end system, large table sizes can easily make full-table caching infeasible because of increased replication and maintenance costs in a database cache. Deepening this approach, sub-table caching provides an effective alternative by caching only selected parts of backend database tables. Materialized view mechanisms in current database products can be exploited for this purpose. Materialized views are developed to store pre-computed query results that are later used to improve performance and speed data access of expensive queries.
Nicknames in DB2™ are references to remote tables that can be used in federated queries. In order to implement a sub-table cache, in particular by creating materialized views based on nicknames, extra processing effort is not required. This way, existing materialized view-matching mechanisms in DB2™ can be exploited to route queries to either cached tables, by materialized views, or to backend tables, by nicknames depending on query predicates. However, in a database cache, this approach is limited in that materialized views require declarative specification. Once specified, the definition of materialized view content cannot change dynamically based on demand. Unfortunately, it is difficult, if at all possible, to know a priori exactly what to cache because of the dynamic nature of web applications (e.g., caching the content of a shopping cart in a typical e-commerce application).
As described in the product documentation entitled “Oracle Internet Application Server Documentation Library,” by Oracle Corporation, and the non-patent literature entitled “Mid-tier Caching: The FrontTier Approach,” by The TimesTen Team, Oracle™ and TimesTen offer database cache products of interest. The Oracle™ approach involves full-table caching using a full-fledged database server at a middle tier between remote data centers and a central backend database, in which updates are propagated through replication. Their solution ensures that other database objects, including stored procedures and user-defined functions, are deployed in the middle-tier, from a central backend database, as well. Although this approach has the advantage of considerable application transparency, it requires considerable cache population and management tasks for large tables. On the other hand, the TimesTen Front-Tier approach allows sub-table level caching and local updates at cache databases. However, an application utilizing such a cache needs to be made aware of the freshness of cache content and choose a target database (i.e., cache or backend) accordingly. Moreover, the TimesTen Front-Tier approach is restricted to work only with an Oracle™ backend database. A cache group first introduced by The TimesTen team is defined solely based on referential integrity constraints of a backend database and is therefore less restrictive.
Whatever the precise merits, features, and advantages of the above cited references, none of them achieves or fulfills the purposes of the present invention.